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(57) ABSTRACT 

A Component Transaction Server (CTS) is described, which 
provides a framework for deploying the middle-tier logic of 
distributed component -based applications. The CTS simpli- 
fies the creation and administration of Internet applications 
that service thousands of simultaneous clients. The CTS 
components, which execute on the middle-tier between 
end-user client applications and remote databases, provide 
efficient management of client sessions, security, threads, 
third-tier database connections, and transaction flow, with- 
out requiring specialized knowledge on the part of the 
component developer. The system's scalability and platform 
independence allows one to develop application on inex- 
pensive uniprocessor machines, then deploy the application 
on an enterprise-grade multiprocessor server. In its Result 
Set module, the CTS provides tabular result sets, thus 
making the environment very desirable for business appli- 
cations. In most component-based systems, a component 
interface returns an object. CTS components can return 
either an object or a collection of objects called a "result 
set." The format of a result set is based on the standard 
ODBC result set, and it is roughly equivalent to a database 
cursor. Because they return a result set, CTS components are 
much simpler and more efficient to work with. In this 
fashion, graphic user interface (GUI) development with CTS 
is nearly identical to traditional two-tier systems. 

35 Claims, 7 Drawing Sheets 
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COMPONENT TRANSACTION SERVER FOR 
DEVELOPING AND DEPLOYING 
TRANSACTION- INTENSIVE BUSINESS 
APPLICATIONS 

RELATED APPLICATIONS 

The present application claims the benefit of priority from 
and is related to the following commonly-owned U.S. pro- 
visional applications: application Ser. No. 60/058,199, 
entitled Component Transaction Server For Developing and 
Deploying Transaction-Intensive Business Applications, 
filed Sep. 23, 1997, and application Ser. No. 60/080,192, 
entitled Component Transaction Server for Developing and 
Deploying Transaction-Intensive Business Applications, 
filed Mar. 31, 1998. The disclosure of which is hereby 
incorporated by reference. The disclosures of the foregoing 
applications are hereby incorporated by reference in their 
entirety, including any appendices or attachments thereof, 
for all purposes. 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

BACKGROUND OF THE INVENTION 

The present invention relates generally to distributed 
computing systems and, more particularly, to a system and 
methods for improving data access and operation in distrib- 
uted computer environments. 

Today, most computers are linked to other computer 
systems via a computer network. Well-known examples of 
computer networks include local-area networks (LANs) 
where the computers are geographically close together (e.g., 
in the same building), and wide-area networks (WANs) 
where the computers are farther apart and are connected by 
telephone lines or radio waves. 

Often, networks are configured as "client/server" 
networks, such that each computer on the network is either 
a "client" or a "server." Servers are powerful computers or 
processes dedicated to managing shared resources, such as 
storage (i.e., disk drives), printers, modems, or the like. 
Servers are often dedicated, meaning that they perform no 
other tasks besides their server tasks. For instance, a data- 
base server is a computer system that manages database 
information, including processing database queries from 
various clients. The client part of this client-server architec- 
ture typically comprises PCs or workstations which rely on 
a server to perform some operations. Typically, a client runs 
a "client application" that relies on a server to perform some 
operations, such as returning particular database informa- 
tion. 

Often, client-server architecture is thought of as a "two- 
tier architecture/' one in which the user interface runs on the 
client or "front end" and the database is stored on the server 
or "back end." The actual business rules or application logic 
driving operation of the application can run on either the 
client or the server (or even be partitioned between the two). 
In a typical deployment of such a system, a client 
application, such as one created by an information service 
(IS) shop, resides on all of the client or end-user machines. 
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Such client applications interact with host database engines 
(e.g., Sybase® SQL Server™), executing business logic 
which traditionally ran at the client machines. 

More recently, the development model has shifted from 

5 standard client/server or two-tier development to a three-tier, 
component-based development model. This newer client/ 
server architecture introduces three well-defined and sepa- 
rate processes, each typically running on a different plat- 
form. A"first tier" provides the user interface, which runs on 

10 the user's computer (i.e., the client). Next, a "second tier" 
provides the functional modules that actually process data. 
This middle tier typically runs on a server, often called an 
"application server." A "third tier" furnishes a database 
management system (DBMS) that stores the data required 

35 by the middle tier. This tier may run on a second server 
called the database server. 

The three-tier design has many advantages over tradi- 
tional two-tier or single-tier designs. For example, the added 
modularity makes it easier to modify or replace one tier 

20 without affecting the other tiers. Separating the application 
functions from the database functions makes it easier to 
implement load balancing. Thus, by partitioning applica- 
tions cleanly into presentation, application logic, and data 
sections, the result will be enhanced scalability, reusability, 

25 security, and manageability. 

In a typical client/server environment, the client knows 
about the database directly and can submit a database query 
for retrieving a result set which is generally returned as a 

3Q tabular data set. In a three-tier environment, particularly a 
component-based one, the client never communicates 
directly with the database. Instead, the client typically 
communicates through one or more components. Compo- 
nents themselves are defined using one or more interfaces, 

35 where each interface is a collection of method. In general, 
components return information via output parameters. In the 
conventional, standard client/server development model, in 
contrast, information is often returned from databases in the 
form of tabular result sets, via a database interface such as 

40 Open Database Connectivity (ODBC). A typical three-tier 
environment would, for example, include a middle tier 
comprising business objects implementing business rules 
(logic) for a particular organization. The business objects, 
not the client, communicates with the database. 

45 Nevertheless, there is still the desire to have client/server 
features, such as scrollable results and data input fields. 

Since existing tools were created for the client/server 
model, they are better suited or adapted to receiving table - 
based or tabular "result sets" for retrieving complex data. 

50 Also, tabular data tends to be a more efficient way to retrieve 
data from a relational database, such as from Sybase® SQL 
Server. At the same time, however, components provide 
distinct advantages. In particular, they provide a well- 
designed model and interface, so that reusable code is 

55 achievable with minimal effort. 

One common mechanism for retrieving tabular data 
through component-based interfaces is to return output 
parameters in the form of arrays of structures, or arrays of 
objects. The approach is problematic, however. First, 

60 present-day automated development tools that allow a devel- 
oper to rapidly build application programs are tied to tabular 
data interfaces, such as ODBC. Such tools allow the devel- 
oper to "bind" the visual controls to relational data, quickly 
build forms for data entry, and quickly generate reports for 

65 reporting information of interest. Quite simply, components 
that return arrays of structures cannot participate in this level 
of automation. Second, existing network transport mecha- 
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nisms for returning these kinds of structures tend to have The CTS is middleware, an application server. Compo- 

poor performance. Traditional transport mechanisms have nents installed on the CTS become usable across whatever 

generally been much better suited at transporting tabular network the CTS is connected to (which can include the 

data. Internet). In accordance with the present invention, a sim- 

What is needed is a solution in which provides a simpli- s plified database connectivity interface is provided for com- 

fied database connectivity interface for communicating with municating with components, including JavaBeans, Java 

components, including Java and ActiveX components, as classes, ActiveX controls, and even DLLs (Dynamic Link 

well as conventional C components, such that the interfaces Libraries). The interfaces of the components can be called 

of the components can be called for returning a tabular result for returning a tabular result set to the client. In a corre- 

set to the client. The present invention fulfills this and other io sponding manner, a component (i.e., collection of methods) 

needs. is provided at the client such that any one of its methods is 

SUMMARY OF THE INVENTION for , rc '™ tabu,ar rcsi f ts - ^ hen Y 1 ^ s ^ m 

generates a stub for Java or a proxy tor ActiveX, the system 
A Component Transaction Server (CTS) is described, makes ta bular results available through standard interfaces, 
which provides a framework for deploying the middle-tier 15 In the instance of a Java component, for example, the system 
logic of distributed component-based applications. The CTS ma kes the results available through the JDBC (Java Data- 
simplifies the creation and administration of Internet appli- 5^ Connectivity) interface. Here, a client can invoke a 
cations that service thousands of simultaneous clients. The met hod on a component and request the results as a tabular 
CTS components, which execute on the middle-tier between data set< p or a j ava component, the client can request a 
end-user client applications and remote databases, provide 20 JDBC result han dle (i.e., database cursor). In a visual 
efficient management of client sessions, security, threads, development environment, such a handle could then be 
third-tier database connections, and transaction flow, with- bound to a visual control or component, provide providing 
out requiring specialized knowledge on the part of the both component-based development and tabular data, 
component developer. The system's scalability and platform ^ ^ removcs from ^ devcl anv concern for 
independence allows one to develop application on inex- 25 transactkm management details . Any component installed in 
pensive umprocessor machines, then deploy the application ^ server ^ a caadidate for artici ation in a transact ion. 
on an enterprise-grade multiprocessor server. More important, no component in a transaction need con- 
The CTS architecture supports a variety of thin-client cem itsdf with me behavior of other components in regards 
front ends, including Java applets deployed on the Internet tQ their effect on the transaction-CKS handles all the 
or Web, PowerBuilder™ clients deployed on a standard 30 details. For instance, suppose one has three components — A, 
desktop, or any ActiveX client. Web-based clients commu- ^ and c _ for use in a transaction. The CTS provides a 
nicate with server components executing in the CTS kernel versatile apt thal components call in order to keep the server 
using HTTP (HyperText Transport Protocol) and an HTTP mformed of ea ch component's transaction state. So, if 
server embedded in CTS. Windows-based clients commu- components A and B succeed, while component C fails, the 
nicate with server components using a streaming protocol, 35 CTS aborts ^ oyeraU frailsaction and dea i s w j th the dirty 
such as Sybase® Tabular Data Stream (TDS) protocol. WOfk of roUbacks on whatever database resources A 
The CTS kernel includes a Session Management module, and B were communicating with. As mentioned, CTS is not 
a Security module, a Result Set module, a Thread Polling limited to Java components. ACTS or Jaguar component can 
module, a Transaction Management module, and a Connec- as easily ^ a C/C++ DLL or an ActiveX control. So, a 
tion Pooling module. Components execute within the CTS 40 client-side application written in Java cannot only remotely 
multithreaded kernel which provides automatic optimization invoke a JavaBean or Java class, it can as easily invoke a 
of available system resources. By pooling and reusing C/C++ routine in a DLL or an ActiveX control. Similarly, a 
resources such as threads, sessions, and database CTS client could be an ActiveX control, calling a JavaBean 
connections, the CTS eliminates significant system over- or a C/C++ DLL. 

head. Here^CTS component execute on native threads 45 The ^ ides |he nec tools for gencratmg lhe 

w.thm the CTS kernel. The CTS maintains a pool of threads stub ffles needed for a Jaya dfcnl tQ communicate with a 

and allocates them to components as needed Componen s crg nent ( dless of the component's species), 

can be configured as single- threaded or multithreaded. If ^ smb fiks ^ minimum methods lhat a ar t0 

multithreaded, a thread can be allocated for the life of the ^ Java ^ Ucation as the methods of me rcmo te 

component instance, or, for better scalability, a new thread 50 nent ^ {hio the stub is ^ code that establishes a 

can be allocated on each method invocation. ^ ^ CTS seryer aQd commands me to 

In the Result Set module, the CTS provides tabular result msta n t i ate the actual component. The stub also handles the 

sets, thus making the environment very desirable for busi- dient end of marsnaling lhe data between the client and the 

ness applications. In most component-based systems, a server 

component interface returns an object. CTS components can 55 

return either an object or a collection of objects called a BRIEF DESCRIPTION OF THE DRAWINGS 

"result set." The format of a result set is based on the rjr , A A . , . . ,. c _ :„ „ T u;~u 

i , ^r^n^ 1. . j . ■ 1 44 FIG. lAis a block diagram of a computer system m which 

standard ODBC result set, and it is roughly equivalent to a . • _ . „ . 

, n . . i. r-rc the invention may be embodied, 

database cursor. Because they return a result set, CTS J 

components are much simpler and more efficient to work 60 FIG. IB is a block diagram of a computer software system 

with. For instance, result sets can be bound directly to provided for directing the operation of the computer system 

data-aware controls such as a PowerBuilder® DataWindow, of FIG * 1A * 

a Sybase® PowerJ Grid control, or any data-aware control FIG. 2 is a block diagram illustrating the general structure 

that can be bound to an ODBC result set. In this fashion, of a Three-tier Database System suitable for implementing 

GUI development with CTS is nearly identical to traditional 65 the present invention. 

two- tier systems. The CTS automatically manages partial FIGS. 3-6 are bit map screen shots illustrating a visual 

refreshes and updates of the result set. development environment (e.g., PowerBuilder®) where a 
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client can invoke a method on a component and request the Client/Server Database Management System 

results as a tabular data set, using the system of the present A. General 

invention. While methods of the present invention may operate 

_ „ „ _ VT within a single (standalone) computer (e.g., system 100 of 

DETAILED DESCRIPTION OF A PREFERRED 5 F[G ^ { £ p ^ nl inv J tion £ pn £j^ / mbodied in a 

EMBODIMENT multi-tier computer system, such as a Three-tier Client/ 
The following description will focus on the presently- Server system. FIG. 2 illustrates the general structure of a 
preferred embodiment of the present invention, which is Three-tier Database System 200 suitable for implementing 
operative in a network environment executing component- the present invention. As shown, the system 200 comprises 
based multi-tier application programs which interact with 10 one or more Thin Qient(s) 210 (e.g., Java client 211, 
remote data, such as stored on an SQL database server. The ActiveX client 213, and PowerBuilder client 215) connected 
present invention, however, is not limited to any particular to Back End Servers (e.g., Sybase database server 231, 
application or environment. Instead, those skilled in the art mainframe (e.g., IBM DB2) 233, and Oracle database server 
will find that the present invention may be advantageously 235) via a middle tier 220 comprising a Component Trans- 
applied to any application or environment where optimiza- 15 action Server (CTS) 221. In an exemplary embodiment, the 
tion of query performance is desirable, including non-SQL Clients may themselves include standalone workstations, 
database management systems and the like. The following dumb terminals, or the like, or comprise personal computers 
description is, therefore, for the purpose of illustration and (PCs) such as the above-described system 100. Typically, 
not limitation. such units would operate under a client operating system, 
Standalone System Hardware 20 such as Microsoft Windows 9x for PC clients. Each Back 
The invention may be embodied on a computer system End Server, such as Sybase® SQL Server™, now Sybase® 
such as the system 100 of FIG. 1A, which comprises a Adaptive Server™ (available from Sybase, Inc. of 
central processor 101, a main memory 102, an input/output Emeryville, Calif.) in an exemplary embodiment, generally 
controller 103, a keyboard 104, a pointing device 105 (e.g., operates as an independent process (i.e., independently of 
mouse, track ball, pen device, or the like), a screen display 25 the Clients), running under a server operating system such as 
device 106, and a mass storage 107 (e.g., hard or fixed disk, Microsoft Windows NT (Microsoft Corp. of Redmond, 
removable disk, optical disk, magneto-optical disk, or flash Wash.), NetWare (Novell of Provo, Utah), UNIX (Novell), 
memory). Processor 101 includes or is coupled to a cache or OS/2 (IBM). 

memory 109 for storing frequently accessed information; The components of the system 200 communicate over a 
memory 109 may be an on-chip cache or external cache (as 30 network which may be any one of a number of conventional 
shown). Additional output device(s) 108, such as a printing network systems, including a Local Area Network (LAN) or 
device, may be included in the system 100 as desired. As Wide Area Network (WAN), as is known in the art (e.g., 
shown, the various components of the system 100 commu- using Ethernet, IBM Token Ring, or the like). The network 
nicate through a system bus 110 or similar architecture. In a includes functionality for packaging client calls in the well- 
preferred embodiment, the system 100 includes an IBM- 35 known SQL (Structured Query Language) together with any 
compatible personal computer system, available from a parameter information into a format (of one or more 
variety of vendors (including IBM of Armonk, N.Y.). packets) suitable for transmission across a cable or wire, for 
Standalone System Software delivery to the database servers. 

Illustrated in FIG. IB, a computer software system 150 is Client/server environments, database servers, and net- 
provided for directing the operation of the computer system 40 works are well documented in the technical, trade, and 
100. Software system 150, which is stored in system patent literature. For a discussion of database servers and 
memory 102 and on mass storage or disk memory 107, client/server environments generally, and SQL Server™ 
includes a kernel or operating system (OS) 140 and a particularly, see, e.g., Nath, A., The Guide to SQL Server, 
windows-based GUI (graphical user interface) shell 145. Second Edition, Addison-Wesley Publishing Company, 
One or more application programs, such as application 45 1 995. Additional documentation of SQL Server™ is avail- 
software programs 155, may be "loaded*' (i.e., transferred able from Sybase, Inc. as SQL Server Documentation Set 
from storage 107 into memory 102) for execution by the (Catalog No. 49600). For a discussion of a computer net- 
system 100. The system also includes a user interface 160 work employing Microsoft Networks/OpenNet File Sharing 
for receiving user commands and data as input and display- Protocol, see Method and System for Opportunistic Locking 
ing result data as output. 50 in a Networked Computer System, Intl. Application No. 

Also shown, the software system 150 includes a Rela- PCT/US 90/045 70, Intl. Publication No. WO 91/03024, Intl. 

tional Database Management System (RDBMS) front-end Publication Date Mar. 7, 1991. For a general introduction to 

or "client" 170. The RDBMS client 170 may be any one of a Local Area Network operating under NetWare, see Freed, 

a number of database front-ends, including PowerBuilder™, L. et al., PC Magazine Guide to Using NetWare, Ziff-Davis 

dBASE®, Paradox®, Microsoft® Access, or the like, and 55 Press, 1991. A more detailed discussion is available in 

the front-end will include SQL access drivers (e.g., Borland NetWare 3.x and 4.x and accompanying documentation, 

SQL Links, Microsoft® ODBC drivers, Intersolv® ODBC which is available from Novell of Provo, Utah. The disclo- 

drivers, and the like) for accessing database tables from an sures of each of the foregoing are hereby incorporated by 

SQL database server operating in a Client/Server environ- reference, 

ment. In a most-preferred embodiment, the RDBMS client 60 System Architecture 

comprises PowerBuilder Enterprise 6.0 for Windows, avail- A. Component Transaction Server (CTS) Basic Architec- 

able from Powersoft of Concord, Mass., a wholly-owned ture 

subsidiary of Sybase, Inc. Description of PowerBuilder can The Component Transaction Server (CTS) 221, which in 

be found in the manuals accompanying PowerBuilder Enter- an exemplary embodiment comprises Sybase® Jaguar 

prise; additional description can be found in U.S. Pat. No. 65 CTS™, provides a framework for deploying the middle-tier 

5,566,330, issued Oct. 15, 1996, the disclosure of which is logic of distributed component-based applications. CTS 221 

hereby incorporated by reference. simplifies the creation and administration of Internet appli- 
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cations that service thousands of simultaneous clients. The 
CTS components, which execute on the middle-tier between 

end-user client applications and remote databases, provide _ 7" , ■ „ q „j 

" , r j^ Qt Tljc component is not able to participate in a transaction and 

efficient management of client sessions, security, threads, supported: will fail if a transaction exists. 

third-tier database connections, and transaction flow, with- 5 Allows: The component does not require a transaction but is able to 

out requiring specialized knowledge on the part of the . participate in a transaction if one exists 

i t r™ » il-t jir Requires: The component requires a transaction. If a transaction exists, 

component developer. The system s scalability and platform ^ component will enlist in that transaction, if a transaction 

independence allows one to develop application on inex- does not exist, it will initiate a new transaction, 

pensive uniprocessor machines, then deploy the application Requires The component requires its own transaction and always 

r r . j , • 10 New: initiates a new transaction even if one exists, 

on an enterprise-grade multiprocessor server. 



The CTS architecture supports a variety of thin-client , .. /A _ , 

r 4 j • , j. , | j j * /„ t . , , t In the Security module 223, access control lists (ACLs) 

front ends including Java applets dep oyed on the Internet can be J ^ Uca ^ n kveh Unauthori zed users 

or Web, PowerBuilder™ clients deployed on a standard ^ prevented from executiDg components within the appli- 

desktop, or any ActiveX client. Web-based clients commu- 15 cation User identity is based on operating system login. 

nicate with server components executing in the CTS kernel [ n tne R esu it Set module 224, the CTS 221 provides 

using HTTP (HyperText Transport Protocol) and an HTTP tabular result sets, thus making the environment very desir- 

server embedded in CTS. Windows-based clients commu- able for business applications. In most component-based 

nicate with server components using a streaming protocol, systems, a component interface returns an object. CTS 

such as Sybase® Tabular Data Stream (TDS) protocol. 20 components can return either an object or a collection of 

a u • 1 *u ptc 1 1 • 1,, j_ n o_- objects called a "result set." The format of a result set is 

As shown in FIG. 2, the CTS kernel includes a Session , ., . . « 

t A 1 c -t a 1* m n d„„i» based on tne standard ODBC result set, and it is roughly 

Management module 222, a Secunty module 223, a Result . „ „ H ™ „ °„u 

0 * * 1 n J n ir .4,1 -r, equivalent to a database cursor. Because they return a result 

Set modu e 224, a Thread Polling module 225, a Transaction ^ , ■ , , ' orRr .- „ f . 

' , , . * i3 i- set, CTS components are much simpler and more efficient to 

Management module 226, and a Connection Pooling module ' r . 1* ♦ w™„,i ,«™.ti., 

~_ 5, f ' .... *u» rro ™,i*Sh«. a H,.ri 25 work with. For instance, result sets can be bound directly to 

227. Components execute wrtun the CTS mu threaded da(a . aware ^ such as , PowerBui , der ™ DataWindow, 

kernel wh.ch provides automatic optimization of available or data . aware 

system resources. By pooling and reding resources such as J ^ ^ ^ ^ ^ 

threads, sess.ons, and database connections^ CTS ehmi- deve]opment ^Ib CTS is nearly identical to traditional 

nates significant system overhead. Here, CTS components f ™ rvro ' i lir mQ „ Q „ M „ ar 

, & *, , ... .. /-rr4 1 1 tu r^rc 30 two-tier systems. The CTS 221 automatically manages par- 

execute on native threads within the CTS kernel He CTS s rf ^ ^ ^ 

mamtains a pool of threads and altocales them to compo- currently-preferred embodiment, the CTS 221 

nents as needed Components car, be configured as smgle- Sybase® Tabular Data Stream, the native Sybase 

n , H°/ 7 l^f.t mul,lthr t ead : d ' 3 threa f d r C h a "^ communications protocol to deliver streams of tabular data, 

allocated for the life of the component instance, or . forbeUei developers and users are not aware of TDS. 

scalability, a new thread can be allocated on each method „., & ' r . , . , „„ t-m _ 

. When ActiveX components are imported into the system, an 

invocation. ActiveX Automation proxy client interface is automatically 

In the Session Management module 222, the CTS 221 generated that transparently converts the ActiveX requests 

maintains a pool of communications sessions and allocates ^ TO§ protocol Automation client proxy and the 

them to clients as needed. Each session maintains the 4Q XDS protocol stack is deployed on each client system. The 

context and state of the connection. As sessions are released, ^ architecture actually supports a variety of communi- 

they are returned to the pool for subsequent clients. In the cation p^coi^ however. The session management service 

Connection Pooling module 227, the CTS 221 also main- prov id es a layer of abstraction between the communications 

tains a pool of database connections that are allocated to protocol and tne components. Therefore, the system can be 

server components as needed. Database connections can be 45 adapted to support other protocols, such as HOP, TDS 

implemented using the Sybase-native CT-Lib interface or tunneled through HTTP or SSL, or the like. 

using ODBC or JDBC interfaces. Component -based Development with Tabular Data 

Transaction management is provided by the Transaction a. Overview 

Management module 226. CTS 221 supports implicit trans- The CTS is middleware, an application server. Compo- 

actions whose properties are defined declaratively at the 50 nents installed on the CTS become usable across whatever 

time that the components are assembled into applications. network the CTS is connected to (which can include the 

Components are automatically enrolled in a transaction, and Internet). In accordance with the present invention, a sim- 

no special coding is required. Jaguar CTS supports full plified database connectivity interface is provided for com- 

two-phase commit (2PC) transactional integrity for multi- municating with components, including JavaBeans, Java 

database updates. To coordinate transactions, the CTS 221 55 classes, ActiveX controls, and even DLLs (Dynamic Link 

can use either Microsoft Distributed Transaction Coordina- Libraries). The interfaces of the components can be called 

tor (DTC) or any transaction coordinator that conforms with for returning a tabular result set to the client. In a corre- 

the Java Transaction Service (JTS), a Java enterprise service sponding manner, a component (i.e., collection of methods) 

based on the Open Group Distributed Transaction Process- js provided at the client such that any one of its methods is 

ing (D-TP) standard. The CTS 221 supports asynchronous 6Q mar ked for returning tabular results. When the system 

transactions using the Sybase database queuing service, generates a stub for Java or a proxy for ActiveX, the system 

dbQ. makes tabular results available through standard interfaces. 

The transactional semantics of an application component In the instance of a Java component, for example, the system 

are defined through its transaction properties. These prop- makes the results available through the JDBC (Java Data- 

erties are functionally equivalent to the transaction proper- 65 base Connectivity) interface. Here, a client can invoke a 

ties supported within me Microsoft Transaction Server method on a component and request the results as a tabular 

(MTS). Transaction semantics include: data set. For a Java component, the client can request a 
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JDBC result handle (i.e., database cursor). In a visual 
development environment, such a handle could then be 
bound to a visual control or component, provide providing 
both component-based development and tabular data. 

The CTS removes from the developer any concern for 
transaction management details. Any component installed in 
the server is a candidate for participation in a transaction. 
More important, no component in a transaction need con- 
cern itself with the behavior of other components in regards 
to their effect on the transaction — CTS handles all the 
details. For instance, suppose one has three components — A, 
B, and C — for use in a transaction. The CTS provides a 
versatile API that components call in order to keep the server 
informed of each component's transaction state. So, if 
components A and B succeed, while component C fails, the 
CTS aborts the overall transaction and deals with the dirty 
work of issuing rollbacks on whatever database resources A 
and B were communicating with. As mentioned, CTS is not 
limited to Java components. A Jaguar component can as 
easily be a C/C++ DLL or an ActiveX control. So, a 
client-side application written in Java cannot only remotely 
invoke a JavaBean or Java class, it can as easily invoke a 
C/C++ routine in a DLL or an ActiveX control. Similarly, a 
CTS client could be an ActiveX control, calling a JavaBean 
or a C/C++ DLL. 

The CTS provides the necessary tools for generating the 
stub files needed for a Java client to communicate with a 
CTS component (regardless of the component's species). 
The stub files contain the minimum methods that appear to 
the Java client application as the methods of the remote 
component; within the stub is the code that establishes a 
session with the CTS server and commands the server to 
instantiate the actual component. The stub also handles the 
client end of marshaling the data between the client and the 
CTS server. 

B. Exemplary session; PowerBuilder example 

Operation of the system is perhaps best illustrated by way 
of example. FIG. 3 illustrates a PowerBuilder design win- 
dow or "painter" having a "data window" control for con- 
necting to remote data sources. In this example, the control 
is connected to the Component Transaction Server (Sybase® 
Jaguar CTS™) of the present invention, residing in the 
middle tier and acting as the data source. From the perspec- 
tive of the PowerBuilder environment, the data window 
control in effect "thinks" that it is connected to an SQL data 
source. 

Proceeding with the example, the user will create a new 
data window, such as a stored procedure data window, for 
illustrating that a method on a component can be made to 
look like a stored procedure (i.e., returning a tabular result 
set). At this point, the PowerBuilder environment sends a 
query requesting a list of stored procedures. The component 
transaction server, in response, enumerates what compo- 
nents are on the transaction server and what methods are on 
those components. Thereafter, the component transaction 
server returns a list of the enumerated items, in effect making 
them appear as storage procedures to PowerBuilder, as 
shown by dialog 310. 

Consider as an example, for instance, a component named 
"book store" with a method entitled "get books by title." 
Using a conventional approach, there is no way of knowing 
what results the method will return if one were to simply use 
querying technique. Therefore, conventionally, one is 
required to know beforehand what results are returned by the 
method. Using the approach of the present invention, 
however, this is not required. As shown in FIG. 4, the user 
simply proceeds as follows. First, the user enters expected 
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data types, such as a text type for title and a real (floating 
point) type for price, as shown in dialog 410, and then 
specifies retrieve arguments, as shown in dialog 510 in FIG. 
5. Then, after specifying argument information and indicat- 

5 ing a start and a finish, the information can be executed 
against the component residing on the middle tier, not 
against the database. The data is returned to the client as a 
tabular data set, despite the fact that the method itself is 
simply one which returns books by title. This is shown at 

io 610 in FIG. 6. 

C. Internal opera tion/design 

1. General 

An important aspect of the design is the ability of a 
component to return a result back to the client. From the 

35 perspective of a component writer, the present invention 
provides an application programming interface (API) for 
"pushing" a data set to clients. Interface calls are provided 
for describing every column, binding variables to those 
columns, initializing those variables, and then sending the 

20 data. In the currently-preferred embodiment, the interface is 
defined for Java, ActiveX, and C, thus allowing all compo- 
nent models supported by the system a means to send tabular 
result sets. 

The currently-preferred embodiment employs the inter- 
ns face provided by Sybase® Open Serve™ as follows. One 
module of the component transaction server functions to 
convert native data types of the components to correspond- 
ing ones for Open Server. Once the data types have been 
converted, the component transaction server may then pro- 
30 cee d to retrieve the component data into a memory buffer or 
cache. Thereafter, the component transaction server pro- 
ceeds to invoke to write data out using a streaming tabular 
protocol, such as Sybase® tabular data stream (TDS), or 
CORBA's HOP (Internet InterORB Protocol) streaming 
35 protocol. 

On the client side, the user is able to generate a component 
graphically (e.g., using PowerBuilder or other visual devel- 
opment environment). For a Java component, the system of 
the present invention generates a stub. The stub, which 
40 resembles a Java class, include employs JDBC for sending 
requests to the component transaction server for receiving 
tabular result sets back. 

2. Objects and methodologies for "Methods as Stored 
Procedures" 

45 Three major classes are employed for implementing the 
"Methods as Stored Procedures" (MASP) feature of the CTS 
system: Metadata, Command, and Marshaller. Each will be 
explained in turn. 

50 a. Metadata 

The Metadata class is used to cache metadata information 
about all the components installed in the server. In particular, 
it caches all the method definitions. This, as highlighted 

55 below, is needed for the "Marshaller" to properly parse 
incoming requests from clients. 

Component metadata is also used to support Power- 
Builder™ stored procedure DataWindow™. Powerbuilder 
queries the CTS as though it were a database, asking it what 

60 stored procedures are available. The CTS responds by 
delivering a tabular result set containing the names of all the 
available component methods. This information is acquired 
by iterating through the metadata hash table that was created 
at startup by one of Metadata's methods, 

65 Metadata: :loadMetadata( ). . 

The Metadata class, and its supporting classes, ParamDef 
and MethodDef, may be defined as follows. 
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-continued 



class ParamDcf 
{ 

public: 

ParamDefO; 
-ParamDcfO; 

CS_RETCODE init(CS_CHAR *); 
void destroyO; 
void sctNumber(CS_INT>; 
void setTYpe(CSJNT); 
void setMode(JagParamMode); 
CS_CHAR - getFullName(void); 
CS_CHAR • getShortName(void); 
CS_INT getNumber(void); 
CS_INT geOype(void); 
JagParamMode getModefvoid); 
protected 

CS_CHAR * m_JuHName; 
CS_CHAR * m_shortName; 
CS_INT ni„type; 
CS_INT m_numbei; 
JagParamMode m mode; 

>; 

class MethodDef 
{ 

public: 

MethodDeuQ; 
-MethodDefO; 

CS_RETCODE init(CS_CHAR *pkgname, CS_CHAR "fullName, 
CS_INT 
numparams) 

void destroyO; 

void addParamDef(ParamDef *); 

CS_CHAR * getPackageNameO; 
CS_CHAR * getFullNameO; 
CS_CHAR * getShortNameO; 
CS_INT gctNumParams 0; 

ParamDef ** getParams(); 
// param numbers start at 1 

ParamDef * getParamDef(CS_lNT paramnum); 

CS_INT * getParamTypesO; 
CS_VOID logSelfO; // Write 

member data to the log 

protected: 

CS_ CHAR * m_pkgname; 
CS_CHAR * m_fullName; 
CS_CHAR * m_shortName; 
CS_INT m_numparams; 

ParamDef** nt_pparams, // Array of parameter definitions 
CS_INT * m_pparamTypes; // Array of parameter types 

}; 

class Metadata 
{ 

public: 

static CS__RETCODE loadMetaData(void); 

static CS_RETCODE getMethodDef(CS_CHAR *, MethodDcf ■•); 
protected: 

static JagParamMode getModeF*omString(CS_CHAR *); 
static CS __RETCODE loadMethodsInPackages(AF„ VALUE 
•packages, 

HashTable 'htMethods); 
static CS_RETCODE loadMethodsInComponents(CS_CHAR 
"pkgnainc, 

AF_ VALUE -comps, HashTable 'htMethods); 
static CS_RETCODE loadMethodslnInterfaces(CS_CHAR 
*pkgname, 

CS_CHAR 'compname, AF_ VALUE *mtfis > 

HashTable *htMcthods); 1 
static CS_RETCODE loadMethods(CS_CHAR 'pkgnamc, 

CS_CHAR •fiiHIntfName, 

AF_ VALUE 'methods, HashTable 'htMethods); 
static CS_RETCODE addMethod(CS_CHAR *, AF_SECTION *, 

HashTable •); 

static CS_RETCODE loadParamInfo(CS_CHAR % CS_CHAR % 
ParamDef *); 

static CS_RETCODE getTypeFromJagString(CS_CHAR 
CS_I.NT *); 



static CS„RETCODE loadTVpeStringsfvoid); 

static CS VOID logMeihodDekfrTashTablc *ht); 



}; 



Here, the first two classes, ParamDef and MethodDef, 
basically encapsulate the metadata for parameters and meth- 
ods. The public methods are a series of set and get methods 
for the various elements of this metadata. 

The class Metadata is a series of static methods that are 
used to load the component metadata into a hash table at 
startup, and then to be able to look up the metadata for a 
particular method at runtime. The public routine loadMeta- 

15 Data is called when the server starts up. This routine scans 
the CTS repository, and stores the information about the 
components and their methods in a hash table. The key for 
the hash table is a fully scoped method name (e.g. 
<package>,<component>.<method>). This uniquely identi- 

20 fies a particular method in the server. The public routine 
getMethodDef takes a fully scoped method name and returns 
an instance of MethodDef for that method. This is called by 
Command: :runJaguarStoredProc (described further below). 
This method definition is then passed to the Marshaller for 

25 the current request. This allows the Marshaller to properly 
parse and convert the parameters for the method. 

b. Command 

The Command class, when instantiated as an object, 
30 represents a particular request from a client. It is defined as 
follows. 



35 



class Command 
{ 



public: 

static CS_RETCODE runCommands (void); 
private: 

static CS^RETCODE runCreate (void); 

static CS_RETCODE runlnvoke (void); 
40 static CS_RETCODE runDestroyfvoid); 

static CS_RETCODE runSpScrvcrInfo(void); 

static CS_RETCODE runSpPb50db(void); 

static CS_RETCODE runSpPbProclist (JagPb Version pb Version); 

static CS_RETCODE runSelcct (void); 

static CS_RETCODE runIgnoieCommand(void); 
45 static CS_RETCODE runlgnorcStorcdProc (void); 

static CS_RETCODE runJagStoredProc(CS_CHAR *); 

static CS_RETCODE runShutdown(void); 

static JagCmdType getCmdType(CS__CHAR •cmdstring); 

static CS_INT getVersion(CS_CHAR *versstr); 

static CS_CHAR * getVersionString(CS_INT version); 
50 static CS_BOOL isValidJaguarCommand(CS_CHAR 
* cmdstring); 

>: 



As shown, this class is simply a collection of static methods; 

ss no member data is used. The only public method available 
on this class is runCommands. This method is called by the 
server's request handler when it receives a request from the 
client. The runCommands( ) calls getCmdType to determine 
the type of command. This routine looks up the command 

60 name sent by the client in a static table, which may be 
constructed as follows. 



static_cmdmap CmdMap[] - 
65 { 

{"sp_server_Jnfo'\ CMDTYPE_SP_SERVER_INFO}, 
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-continued 



-continued 



{"Sp_SeRvEr__Info", 

{■"shutdown", 

{"SHUTDOWN", 

{"create", 

{"invoke", 

{"destroy", 

{"sp_pb50db", 

{"sp_pb60db", 

{"sp_pb50proclist'\ 

{*sp_pb60proclisr' ( 

{"sp_mda", 

{"CREATE'*, 

{"use", 

{"USE", 

{"insert", 

{"INSERT", 

{"begin", 

("BEGIN", 

("commit", 

{"COMMIT", 

{"rollback", 

{"ROLLBACK", 

{"select", 

{"SELECT", 

{"grant", 

{"GRANT', 

{"set", 

{"SET', 

("sp_pb50text", 

("sp_pb60text", 

( " sp_datatype_info", 

{ "sp_pb50p rocdes c", 

{ "sp_pb 60pro cdes c", 

{NULL, 



CMDTYPE_SP_SERVER_INFO} , 

CMDTYPE_SHUTDOWN}, 

CMDTYPE_SHUTDOWN} , 

CMDTYPE_CREATE} , 

CMDTYPE_INVOKE}, 

CMDTYPE_DESTROY}, 

CMDTYPE_SP_PB50DB>, 

CMDTYPE_SP_PB50DB}, 

CMDTYPE_SP_PB50PROCLIST} , 

CMDTYPE„SP_PB60PROCLIST} ( 

CMDTYPE„IGNORE„SP}, 

CMDTYPE_IGNORE}, 

CM DTYPE_JGNORE } , 

CM DTYPE_IGNORE } , 

CM DTYPE_IGNORE} , 

CM DTYPE_IGNORE} , 

CM DTYPE_IGNORE}, 

CMDTYPE_IGNORE}, 

CMDTYPE_IGNORE}, 

CMDTYPE_IGNORE}, 

CMDTYPE_IGNORE}, 

CMDTYPE_IGNORE}, 

CMDTYPE_SELECT}, 

CMDTYPE_SELECT}, 

CMDTYPE__IGNORE}, 

CMDTYPE_IGNORE}, 

CM DTYPE_JGNORE } , 

CMDTYPE_IGNORE}, 

CMDTYPE_IGNORE_SP}, 

CMDTYPE_IGNORE_SP}, 

CMDTYPE_IGNORE_sp}, 

CMDTYPE_IGNORE_SP}, . 

CMDTYPE_IGNORE_SP}, 

CMDTYPE_IGNORE} 



runcommaadO 
{ 

Get command name from Marshaller 
Get command type 
switch (command type) 



{ 



case CMDTYPE__IGNORE : 

runlgnoreCommandO; 

break; 
default: 

if (isValidJaguarCommandO) 

{ 

runJaguarStoredProc(cmdName) 



} 



The format of the command name is 
<package>.<component>.<method>. Then, 
runJaguarStoredProc( ) looks up the method in the Metadata 
cache and, if it is found, creates the component, calls the 
method on the component, returns the results to the client, 
and then destroys the component. The basic approach can be 
summarized as follows, again in pseudo-code. 



runJaguarStoredProc(string cmdName) 



25 



{ 



} 



marshaller - Marshaller for this request 

mdef - Metadata::getMethodDef(cmdName) 

marshaller->setMethodDef(mdef) 

parse cmdName into package, component, and method 

comp - create component(pkg, comp) 

comp->invoke{method) 

delete component 



Note that the method definition is passed into the Marshaller, 
so that the Marshaller knows the expected types of the 
parameters, and how many to expect, as it parses the 
30 command buffer. 

c. Marshaller 



As shown, many commands are ignored by the CTS. This is 
done in an effort to "mimic" an actual database server. Here, 
the client thinks it is talking to a database server, but it is 
actually talking to the CTS. Certain applications running on 
a client, such as Powerbuilder™, will attempt to create 
tables and insert data that contain database metadata. These 
operations are not supported in a middle-tier transaction 
server, so the CTS "pretends" to do it and simply return a 
success. Although this approach is not always successful, in 
a large percentage of situations it allows the system to work 
with these types of clients. 

Once ranCommand( ) gets the command type, it uses this 
in a switch statement to determine which static method on 
the Command class to run. If there is no match in the static 
table, runCommand( ) assumes this is a client attempting to 
invoke a method on a component as though it were a stored 
procedure in a database. It first calls is 
ValidJaguarCommand( ), to make sure the syntax is OK, and 
then calls runJagStoredProc{ ). 

In pseudo-code, the basic approach is as follows. 



35 



The Marshaller is basically responsible for parsing incom- 
ing requests from clients and for delivering responses back 
to clients. There are two ways a client can send a request to 
the server. One is through a simple ASCII text buffer, such 
as 

"exec My Package. BigComponent.FunMethod 2, 'string 
param', 47" 

This is called a language request. 

The other mechanism is as a remote procedure call, called 
an RPC request. In this case, the procedure name and its 
parameters are "pre-parsed" by the client. Rather than a long 
string buffer, the data for an RPC is accessed by calling a 
series of Open Server (i.e., Sybase®Open Server™) meth- 
ods. To get the procedure name, srv__rpcname() is called. To 
get parameters, a series of methods (srv_descfmt( ), srv__ 
bind, srv^xferdata) are called for each parameter. Each 
parameter can be of any type, whereas parameters in a 
language request are character strings. 

Although the mechanisms for accessing the procedure 
name and parameters are quite different, the end result is 
identical: a client is requesting an invocation of a component 
method. This similar behavior is encapsulated in the abstract 
Marshaller class. There are two concrete implementations of 
this class, TDSMarshaller and LangMarshaller. TDSMar- 
shaller is a Marshaller that handles RPC requests, including 
Sybase(K TDS protocol. 

The Marshaller, TDSMarshaller and LangMarshaller may 
be defined as follows. 



class Marshaller 
65 < 

public: 
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-continued 



-continued 



virtual void 
virtual Integer 
virtual void 
virtual void 
virtual MethodDef* 
virtual AnyPtr 



Marshallcr(AnyPti); 
virtual -MarshallerO; 
cnum State {CREATE, DESTROY}; 
const State OetStateO const; 

virtual CS_BOOL gctHasMoreCommands (void); 

setHasMoreCommands(CS_BOOL); 
getRowsAffected (void); 
setRowsAffected(Integer); 
setMethodDef(MethodDef •); 
getMethodDeffvoid); 
getStreamPtrfvoid); 
virtual Status newCommand(void) = 0; 
virtual Status getCommandName(char *, Integer) = 0; 
virtual Status getDBName(char \ Integer) •» 0; 
virtual Status getOwner(char Integer) « 0; 
virtual Status getCommandVersion(chai Integer) = 0; 
virtual CS_CHAR * getFullCornmandString(void) • 0; 
virtual Integer getNumParams(void) = 0; 
virtual Status getAParam(ParamData&) = 0; 
virtual Status getAHParflrns(ParamList&) = 0; 
virtual Status sendAParam(ParamData&) » 0; 
virtual Status sendAllParams(ParamLUt&) 0; 
virtual Status sendStatus(Status) - 0; 
virtual Status sendDone (Status) - 0; 
protected; 

m_readlndex; 

m numparams; 

streamPtr; 

m_JiasMoreCommands; 
m_rows Affected; 
m_pmdcf; 



Integer 
Integer 
AnyPtr 
CS_BOOL 
Integer 
MethodDcf ' 
private: 

State_State; 

void ChangeStatc(const State); 

}; 

class TDSMars bailer : public Mars nailer 
{ 

public; 

TDSMarshaller (AnyPtr); 

virtual -TDSMarshallerO; 

virtual Status newCommand(void); 

virtual Status getCommandName(char *, Integer); 

virtual Status getDBName(char *, Integer); 

virtual Status getOwner(char Integer); 

virtual Status getCommandVersion(char *, Integer); 

virtual CS_CHAR * getFullCommandString(void); 

virtual Integer getNumParams(void); 

virtual Status gelAParam(ParainData&); 

virtual Status getAllParams (ParamListA); 

virtual Status sendAParam(ParamData&); 

virtual Status sendAllParams(ParamList&); 

virtual Status sendStatus(Status); 

virtual Status sendDone(Status); 
protected: 

char m„cmdname [ CS_MAX_CHAR]; 

Integer m_cmdnamelen; 

char m_version[100]; 

Integer m_version!en; 

char m_dbname[CS_MAX__CHAR]; 

Integer m_dbnamelen; 

char m_ownerlCS_MAX_CHAR]; 

Integer m ownerlen; 

char *m_fullCommandString; 
Integer m_fullCommandLen; 



* This provides an implementation of TDS Marshallcr 

* where the request came in as a LANGUAGE request. 

* One thing the Lang Marshaller needs is a list af types 

* for the expected params, so it can correctly implement 

* gctAparam and getAllParams. 

" Also, a Language request can contain multiple commands, 

* whereas an RPC request can have only one. 



class TDSLangMarshaller : public TDSMarshaller 



public: 

TDsLangMarshallcr (AnyPtr); 
virtual -TDsLangMarshallcr Q; 
virtual Status init(CS„CHAR "langbuf); 
virtual Status ncwCommand(void) 
virtual Status getAParam(ParamData&); 
virtual Status getAllParams(ParamList<&); 
virtual Status sendAParam(PaxamData&); 
virtual Status sendAllParams(ParamList&); 
virtual Status sendDone(Status); 
protected: 



CS_INT * 
CS_CHAR * 
CS_CHAR • 
CS_CHAR * 
Integer 

CS_CONTEXT • 
Integer 
private: 
Status 

Status 
Status 
int 

static int 
static int 



m_paramTypes; 
m__langcmd; 
m_langptr; , 
m_curword; 

m wordlen; 

m_contextp; 
m_wntelndex; 



// for output params 



getDestLength(CS_INT, CS_INTT, 

CS_INT*); 

nextWord(void); 

getWord(char **); 

getWordLength(void); 

IsDoubleQuote(char); 

IsSingleQuote(char); 



{ 



Of interest herein, the first set of methods, such as 
getMethodDef( ) and setMethodDef( ), are used to get and 
set properties on the Marshaller. The next set of methods are 

30 employed for getting or setting information about the current 
request. For example, a language buffer can contain multiple 
requests. The method newCommand( ) tells the Marshaller 
that the system has fully processed the previous request and 
that it is ready for a new one. The Marshaller assumes that 
the next token in the language buffer is the command name. 

35 Also of interest are routines to read in parameters and to 
send output parameters back to the client. LangMarshaller 
inherits from TDSMarshaller, and is therefore able to del- 
egate many of its methods up to TDSMarshaller. LangMar- 
shaller reimplements methods only where necessary. This is 

40 particularly true when it comes to parsing parameters off of 
the language buffer. Many of the private methods on Lang- 
Marshaller are helper functions for parsing the language 
buffer. 

A Marshaller instance is created when a new request 

45 comes in from a client. If the request is a RPC request, a 
TDSMarshaller is created. If the request is a language 
request, an instance of LangMarshaller is created. The 
pointer to this instance is then saved into thread-local 
storage. Any method that needs access to the Marshaller for 

50 this request can simply pull it out of this storage. 

An aspect of the Marshaller that is of particular interest is 
how the Language Marshaller uses the method metadata to 
convert the string representations of the parameters into the 
types the component expects when the method is invoked. 

55 The first step of this process is done by Command: :runJag- 
uarStoredProc. As shown above, it looks up the MethodDef 
instance for the current method request by caDing Metadat- 
a::getMethodDef. This instance is then passed to the Mar- 
shaller using Marshaller ::setMethodDef. This method defi- 

60 nition is ignored by the TDSMarshaller, but is important for 
the LangMarshaller. 

Once the "method def ' is set up, Command: :runJaguar- 
StoredProc then invokes the method. This results in a 
component skeleton or dynamic dispatcher being called. 

65 This skeleton calls the Marshaller method getAParam( ) 
whenever it needs a parameter. It receives a ParamData 
object which contains not only the parameter data but 
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information about the parameter such as its maximum length 
and its datatype, as follows. 



class ParamData 
{ 

public: 

ParamData 0; 
ParamData (CS_CHAR " 
CS_BOOL); 
virtual -ParamData 0; 



CS_BYTE CS_INT, CS_INT, 



CS_BYTE 
CS^CHAR 
CS_DATAFMT 
CS_INT 
CS_BYTE 
char 

CS_BOOL 

CS_BOOL 

CS_INT 

CS_INT 

CS_INT 

CS_INT 

CS_SMALLIOT 

CS_SMALLINT 

void 

void 

void 

void 

CS RETCODE 



private: 
protected: 
CS_INT 
CS_DATAFMT 
CS_INT 
CS_BYTE 
CS_CHAR 
CS„SMALUNT 



}; 



"getDataFointer (void); 
•getDescription (void); 
•getDataFmtPointei (void); 
•getDataLengthPointer (void); 
*getOutputParamPointer (void); 
*getName (void); 
isOutput (void); 
isNull (void); 
getlndex (void); 
gfitDataType (void); 
getDataLength (void); 
getMaxDataLength (void); 
getNullIndicator (void); 
*getNullIndpointer Q; 
setlndex (CS_INT); 
setDescription (CS_CHAR *); 
setDataPointer (CS _J3YTE *); 
setDataLength (CS_[NT); 
set Element (CS_CHAR *, CS_BYTE * 
CS„INT, 

CS_INT, CS„BOOL); 



paramlndex; 
dataFmt; 
data Length; 
*dataBuf; 

description [CS_MAX_CHAR]; 
nulllndicator, 



The basic methodology for LangMarshaller::getAParam( ) 
may be summarized as follows. 



LangMarshaller::getAparam(ParamData &pdata) 



{ 



} 



paramindex++ 

pdef = paramdefs[paramindex] 

ptype - pdef->getTypeO 

get next token in language buffer 

convert the token from string to ptype 

set pdata->type to ptype 

set pdata->data to converted data 

set other miscellaneous info in pdata 



Various errors can occur during this process. For example, it 
may not be possible to convert the current token to the 
expected type, for instance, due to a type mismatch or a 
syntax error. Or, there may not be any more tokens even 
though one is expected. 

Sending output params back to the client is much more 
straightforward. Both TDSMarshaller and LangMarshaller 
use existing Sybase® Open Server™ API calls (e.g., srv_ 
descfrnt( ), srv_bind( ), srv_xferdata( ) to do this in a 
straightforward manner 

3. Sending Results 

A particular advantage of the MASP interface is that it 
truly does look like a database stored procedure. This 
includes the ability for a CTS method to send back tabular 
result sets as if these results came from a database table. 

The CTS provides APIs in C, ActiveX and Java, that allow 
a component writer to describe, populate, and deliver tabular 



results to the client. These APIs, for the most part, map to an 
open interface, such as APIs in Sybase® Open Server™. 
TTiere is minimal new code in Jaguar to make this work — 
most of it is mapping between the component's language 
and/or component model and Open Server. 

By allowing CTS to look like a database and execute 
component methods as stored procedures, a wide range of 
existing, easy-to-use tools can immediately take advantage 
of CTS, using its remote stored procedure mechanism. 
Examples include Powerbuilder™, PowerJ™, 
PowerDynamo™, Microsoft VisualBasic, and Sybase® 
Adaptive Server Enterprise™. 

While the invention is described in some detail with 
specific reference to a single preferred embodiment and 
certain alternatives, there is no intent to limit the invention 
to that particular embodiment or those specific alternatives. 
Thus, the true scope of the present invention is not limited 
to any one of the foregoing exemplary embodiments but is 
instead defined by the appended claims. 

What is claimed is: 

1. In a system comprising a computer network having a 
database server and a client, a method for providing the 
client with component-based access to tabular data from the 
database server, the method comprising: 

providing a component-based transaction server, said 
transaction server in communication with both the 
client and the database server; 

registering the particular component with the transaction 
server so that the particular component is accessible 
across the network to the client, said particular com- 
ponent comprising a plurality of methods; and 

providing the client with component-based access to 
tabular data from the database server by: 

(i) providing an interface allowing the client to request 
a tabular data set by invoking a particular method of 
the component; and 

(ii) upon receiving such a request from the client to 
retrieve data from the database server, processing 
said request by creating at the transaction server a 
result set satisfying said request and transmitting said 
result set to the client as a tabular data set. 

2. The method of claim 1, wherein said client resides on 
a first tier, said transaction server resides on a second tier, 
and said database server resides on a third tier. 

3. The method of claim 1, wherein said tabular data 
comprises a data set arranged in row-based format. 

4. The method of claim 1, wherein said database server 
comprises a relational database management system 
(RDBMS). 

5. The method of claim 1, wherein said particular com- 
ponent comprises a selected one of a Java component, a Java 
Bean component, an ActiveX component, and a C/C++ 
component. 

6. The method of claim 1, wherein said interface com- 
prises a database connectivity interface supporting compat- 
ibility with Java Database Connectivity (JDBC) protocol. 

7. The method of claim 1, wherein said particular method 
of the component comprises a data access method. 

8. The method of claim 1, wherein step (ii) includes 
transmitting from the database server to the transaction 
server a tabular result set satisfying said request. 

9. The method of claim 8, wherein said tabular result set 
is transmitted from the database server to the transaction 
server as a result of a database query transmitted from the 
transaction server to the database server, 

10. The method of claim 9, wherein said database query 
is formulated based on information sought by the client. 
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11. The method of claim 1, wherein step (i) further 20. The system of claim 16, wherein the registered 
comprises: component comprises a selected one of a Java component, 

creating a proxy allowing the transaction server to process a Java Bean component, an ActiveX component, and a 

a request from the client to retrieve data. C/C++ component. 

12. Trie method of claim 1, wherein said request is s 21. The system of claim 16, wherein said connectivity 
transmitted at least in part using HyperText Transport Pro- interface supports compatibility with Java Database Con- 
tocol (HTTP). nectivity (JDBC) protocol. 

13. The method of claim 1, wherein said transaction 22. The system of claim 16, wherein said particular 
server and said database server communicate at least in part method of the component comprises a data access method, 
using a tabular data streaming protocol. 10 23. The system of claim 16, wherein transaction server 

14. The method of claim 1, wherein said transaction processes said request, at least in part, by retrieving into a 
server optionally satisfies said request by returning an local buffer of me transaction server a tabular result set 

0bj A Ct ;„ . , r , j satisfying said request. 

15. rhe method of claim 1, wherein said client includes a 24 ^ ffl of daim ^ wherdn said tabu]ar result ^ 

data aware control and wherein said method further com- 15 fc as a ^ of a transmitted from 

prises binding said tabular data set to the data aware control. 4 . t . tn t . 

r . to r ... 4 .. , , , the transaction server to the database server. 

16. A system for providing a client with component-based c ^ > **a l. • -j j . L 

* *u + ™ 25. The system of claim 24, wherein said database query 

access to tabular data from a database server, the system . „ , , , , . c \. . . i( _ , 

comprising 1 15 f ormu l ated Daseti on information sought by the particular 

a network connected to at least one database server and at 20 ^J^ 1 ' , c , . u . t t - 

.. , 26. The system of claim 16, wherein transaction server 

least one client; . . . . , . . 

processes said request, at least in part, by creating a proxy 

a transaction server connected to the network and in allowing the transaction server to process a request from the 

communication with both a particular client and a particular client t0 retrieve data . 

particular database server, said transaction server for 25 2? ^ system of <Mm 16 wherein said request is 
providing the particular client with component-based transmitte d at least in part using HyperText Transport Pro- 
access to tabular data from the particular database . t0CQ j (j^r*jp) 

server; and 28. The system of claim 16, wherein said transaction 

a connectivity interface allowing the particular client to server and said database server communicate at least in part 

request a tabular data set by invoking a particular 30 us i ng a tabular data streaming protocol. 

method of a component registered with the transaction 29. The system of claim 16, wherein said transaction 

server; server optionally satisfies said request by returning an 

wherein upon receiving such a request from the particular object. 

client to retrieve data from the particular database 30. The system of claim 16, wherein said particular client 

server, the transaction server processes said request by 35 includes a data aware control bound to said tabular data set. 

retrieving from the particular database server a result 31. The system of claim 16, wherein said network is 

set satisfying said request and transmitting said result connected to the Internet. 

set to the client as a tabular data set. 32. The system of claim 16, wherein said particular client 

17. The system of claim 16, wherein said particular client comprises a Web-based client. 

resides on a first tier, said transaction server resides on a 40 33. The system of claim 16, wherein said particular client 

second tier, and said particular database server resides on a comprises a Microsoft Windows-based client. 

third tier. 34. The system of claim 16, wherein the transaction server 

18. The system of claim 16, wherein said tabular data further processes said request by returning a database cursor, 
comprises a data set arranged in row-based format. 35. The system of claim 34, wherein said database cursor 

19. The system of claim 16, wherein said particular 45 comprises a Java Database Connectivity (JDBC) handle, 
database server comprises a relational database management 

system (RDBMS). ***** 
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